Professional Cloud Developer Practice Exam — Professional Cloud Developer

The scenario requires transferring files from an on-premises virtual machine to Google Cloud Storage (GCS) for later consumption by a Dataproc Hadoop cluster. The core requirement here is a reliable, native method to upload local files to GCS, as Dataproc natively supports accessing GCS objects via the gs:// URI scheme once they are stored in a bucket. The recommended tool for GCS object operations is gsutil, which is purpose-built for interacting with GCS, supports features critical for data migration like resumable uploads, integrity checks, and parallel transfers, and does not require Hadoop or Dataproc-specific components to be installed on the source on-premises VM. This approach aligns with GCP best practices for data migration to GCS, as it minimizes unnecessary tooling on the source environment and ensures compatibility with downstream Dataproc workloads. Option Analysis: A. Correct. gsutil is the official, purpose-built command-line utility for Google Cloud Storage operations. The cp subcommand correctly copies local file system objects to GCS buckets using the standard gs:// URI syntax for the destination, which directly meets the requirements of uploading files from the on-premises VM to GCS. This command is part of the Google Cloud SDK, which can be installed on any on-premises machine with minimal overhead. B. Incorrect. The gcloud CLI is the core tool for managing GCP control plane resources such as virtual machines, IAM policies, and Dataproc clusters, but it does not include a native cp command for transferring files to or from GCS. File transfer operations for GCS are delegated to the separate gsutil utility, so this command does not exist as written. C. Incorrect. The hadoop fs cp command is a Hadoop FileSystem shell command designed to run on nodes within a Hadoop environment such as a Dataproc cluster to interact with HDFS or supported storage systems like GCS. Running this command on the on-premises source VM would require a full Hadoop installation and GCS connector configuration on the source machine, which is unnecessary and not aligned with best practices for a simple GCS upload from an on-premises environment. D. Incorrect. The gcloud dataproc command group is used exclusively for managing Dataproc cluster resources, submitting jobs to Dataproc clusters, and configuring Dataproc features. There is no cp subcommand for gcloud dataproc that supports transferring local files to GCS, so this option is an invalid distractor that incorrectly combines Dataproc management functionality with GCS file transfer operations. Key Concepts: 1. GCS CLI Tool Specialization: gsutil is the dedicated command-line utility for all GCS data plane operations including uploads, downloads, and object management, while the gcloud CLI is reserved for control plane management of GCP resources. This separation of tooling is a core GCP operational concept tested in the Professional Cloud Developer certification. 2. Dataproc GCS Compatibility: Dataproc Hadoop clusters include the GCS connector by default, allowing them to natively read and write objects in GCS using the gs:// URI scheme. This means any valid upload method to GCS will produce objects accessible to Dataproc, eliminating the need for Dataproc-specific tools during the upload step. 3. Data Migration Best Practices for GCS: For file uploads from on-premises environments to GCS, using native GCP tooling like gsutil is recommended over Hadoop or service-specific tools, as it reduces dependency overhead on the source environment and includes built-in features to ensure transfer reliability for migration workloads. References: gsutil Tool Overview, https://cloud.google.com/storage/docs/gsutil Use Cloud Storage with Dataproc, https://cloud.google.com/dataproc/docs/concepts/connectors/cloud-storage

The question describes a scenario where an organization has migrated workloads to GCP but retained its existing third-party monitoring platform, which suffers from unacceptably slow notification speeds for time critical issues. The suggested answer C addresses this specific gap without requiring disruptive full replacement of existing tooling, which aligns with core GCP cloud development best practices for migrated workloads. By using Stackdriver (now part of the Google Cloud Operations suite) to capture GCP workload telemetry and trigger low-latency alerts natively on GCP, the organization eliminates the latency associated with sending all telemetry to the external monitoring platform before processing alerts for time critical events. Simultaneously, shipping the same telemetry to the existing monitoring platform preserves all existing workflows, dashboards, reporting, and non-time critical alerting that the organization relies on, avoiding unnecessary migration effort and business disruption. Option Analysis: A. Incorrect. Full replacement of the existing monitoring platform is an unnecessary, high-cost, and disruptive rip and replace approach. The question only identifies slow notifications for time critical problems as a gap, not a complete failure of the existing monitoring platform, so this approach wastes existing organizational investment and requires extensive rework for no added benefit. This violates GCP best practices for minimizing unnecessary change when migrating workloads to the cloud. B. Incorrect. Installing Stackdriver agents on Compute Engine instances only enables collection of additional metrics and logs from GCE workloads, but does not address the core issue of slow notification latency. Even with agent-collected telemetry, if the user continues to rely on the existing slow monitoring platform for alerting, the notification delay remains unresolved. This step is a prerequisite for some monitoring workflows but does not solve the stated problem. C. Correct. This approach directly solves the notification latency gap by leveraging Cloud Operations native low-latency alerting, which is optimized for GCP workloads and can trigger time critical alerts in near-real time without waiting for telemetry to be shipped to the external monitoring platform. At the same time, routing the same logs and metrics to the existing monitoring platform preserves all existing organizational workflows and tooling investments, eliminating unnecessary disruption and rework. This aligns with GCP hybrid monitoring best practices for migrated workloads. D. Incorrect. Migrating traffic back to the pre-migration platform is regressive, undermines the original cloud migration effort, and introduces unnecessary operational complexity. A/B testing of platforms does not address the core issue of slow alerting for GCP-hosted workloads, so this approach fails to resolve the stated problem. Key Concepts: 1. Hybrid Monitoring Best Practices: Google Cloud recommends augmenting rather than replacing existing third-party monitoring tools after cloud migration to fill specific gaps such as low-latency alerting for GCP resources while retaining existing organizational investments and workflows, avoiding unnecessary disruptive full tool replacements. 2. Cloud Operations Alerting Latency: Google Cloud Operations provides near-real-time, low-latency alerting for GCP workloads, with support for log-based and metric-based alerts that trigger in seconds to minutes, making it ideal for time critical incident response for GCP-hosted applications. 3. Telemetry Routing: Google Cloud Logging and Monitoring support configurable routing of logs, metrics, and events to external destinations including third-party monitoring platforms, enabling hybrid monitoring workflows that leverage both native GCP tooling and existing organizational monitoring systems. References: Monitoring hybrid and multi-cloud environments, Route logs to supported destinations, https://cloud.google.com/logging/docs/export

The scenario requires secure connectivity between Compute Engine VMs and a Cloud SQL instance without using IP whitelisting, which is a common requirement for reducing operational overhead and improving security by avoiding public internet exposure. The correct approach leverages native Google Cloud managed private connectivity, which aligns with Professional Cloud Developer best practices for secure, low-maintenance integrations between compute resources and managed database services. Enabling private IP for Cloud SQL eliminates the need to maintain a list of allowed IPs for connecting VMs, as all traffic remains within Google's private network, and access is automatically granted to VMs in the associated VPC without additional IP-based rules. This solution is fully managed, scalable, and meets the stated requirement exactly. Option Analysis: A. Correct. Enabling private IP for Cloud SQL provisions the instance on Google's private service network, which is peered with your VPC via Private Service Access. Compute Engine VMs in the associated VPC can connect directly to the Cloud SQL instance via internal IP address, with no requirement to whitelist any VM IP addresses. This is the native, recommended solution for private, IP-whitelist-free access to Cloud SQL from GCP compute resources. B. Incorrect. Google Cloud SQL does not support project-level whitelisting for database network access. Network access control for public IP Cloud SQL instances relies exclusively on IP address whitelists or the Cloud SQL Auth Proxy, and there is no feature to whitelist an entire project for direct network access, making this option invalid. C. Incorrect. Cloud SQL IAM roles control administrative (management plane) operations on Cloud SQL instances, such as creating backups or modifying instance configurations, not network (data plane) access to the database service itself. Assigning IAM roles to Compute Engine instances does not grant network access to the Cloud SQL database, and no such role for external instance network access exists, so this option is not valid. D. Incorrect. This solution is unnecessarily complex and redundant for the given scenario. A VPN is only required for connecting resources across separate networks outside of Google Cloud, or for specific cross-network configurations that cannot use native VPC peering. Private IP for Cloud SQL provides direct internal access without the need to deploy and manage a VPN, so this option is not the optimal or recommended solution. Key Concepts: 1. Cloud SQL Private IP Access: This feature allows Cloud SQL instances to be accessed via internal IP addresses within a VPC, eliminating public internet exposure and the need for IP whitelisting for resources in the associated VPC. It uses Private Service Access to establish a private peering connection between the customer VPC and Google's managed service network. 2. Cloud SQL Access Control Models: Cloud SQL supports two core network access models: public IP (which requires IP whitelisting or Cloud SQL Auth Proxy for access) and private IP (which uses internal VPC connectivity). IAM permissions for Cloud SQL apply only to administrative operations, not database connection access. 3. Private Service Access: A managed Google Cloud feature that creates a persistent private connection between a customer's VPC and Google's service network, enabling private access to managed services including Cloud SQL, Memorystore, and Filestore without public internet routing. References: About private IP for Cloud SQL, https://cloud.google.com/sql/docs/mysql/private-ip Connect to Cloud SQL from Compute Engine, https://cloud.google.com/sql/docs/mysql/connect-compute-engine

The scenario describes failing health checks for an HTTP(S) Load Balancer targeting Compute Engine instances on port 80, which prevents traffic from being forwarded to the backends. Core GCP load balancing knowledge confirms that health check probes for Google Cloud load balancers originate from fixed, dedicated IP ranges: 130.211.0.0/22 and 35.191.0.0/16. The root cause in this scenario is a missing ingress firewall rule that allows these probe requests to reach the backend instances. The suggested answer C creates an ingress firewall rule on the load balancer's associated network, allowing TCP traffic from the official health check source ranges, which unblocks the probes, resolves the health check failures, and enables traffic forwarding to healthy instances. This directly addresses the stated problem and aligns with GCP best practices for load balancer configuration required for the Professional Cloud Developer certification. Option Analysis: A. This option adds an access config, which assigns a public external IP address to the Compute Engine instance. Health check probes from Google Cloud load balancers do not require backend instances to have public IP addresses, as probes route over Google's internal network. This command does not resolve blocked health check traffic, so it is incorrect. B. This option adds the http-server network tag to the backend instance. Tags only function if there is an existing ingress firewall rule configured to allow traffic to instances with the http-server tag, which is not referenced in the scenario. Even if such a rule existed, it would typically allow traffic from 0.0.0.0/0 rather than the restricted health check source ranges, so this is not the correct resolution. C. This option creates an ingress firewall rule that allows TCP traffic from the dedicated Google Cloud health check source IP ranges to instances on the load balancer network. This explicitly permits health check probes to reach port 80 on the backend instances, resolving the health check failure. This is the correct answer. D. This option creates an egress firewall rule allowing traffic to the health check IP ranges. Health check probes are initiated from Google's infrastructure to the backend instances, so they require an ingress, not egress, rule to be allowed. The direction and destination range configuration here are both incorrect for the scenario, so this option is wrong. Key Concepts: 1. GCP Load Balancer Health Check Source Ranges: All Google Cloud health check probes for load balancing originate from the fixed CIDR ranges 130.211.0.0/22 and 35.191.0.0/16. Ingress firewall rules must explicitly allow traffic from these ranges to backend instance ports used for health checks for load balancing to function correctly. 2. Firewall Rule Direction for Load Balancer Backends: Ingress firewall rules apply to incoming traffic initiated from external sources, including load balancer health checks. Egress rules apply to traffic initiated by the instance, which is not relevant for incoming health check probe requests. 3. Tag-Based Firewall Rule Scope: Network tags only apply firewall rules to instances that have the matching tag assigned. Tag-based rules are not a substitute for explicit CIDR-based rules allowing health check traffic unless the rule is configured with the correct health check source ranges and target tags. References: Health checks overview: Firewall rules, https://cloud.google.com/load-balancing/docs/health-checks#firewall_rules External HTTP(S) Load Balancing overview, https://cloud.google.com/load-balancing/docs/https

The scenario requires a low-overhead method to run A/B/n testing for three website design variants to measure conversion rates, with minimal refactoring from the existing Compute Engine web deployment. The core requirement is native traffic splitting to route controlled portions of user traffic to each design variant without custom infrastructure management. App Engine's built-in traffic splitting feature is purpose-built for this use case, as it allows deploying multiple versions of a single web service and allocating traffic by percentage, user IP, or cookie to support consistent, measurable testing of different application variants. This approach eliminates the need to build custom routing logic, reduces operational overhead, and aligns with GCP best practices for web application testing covered in the Professional Cloud Developer certification. Option Analysis: A. Correct. App Engine natively supports traffic splitting across multiple versions of a single service, which allows you to deploy each of the three website designs as a separate version of the same App Engine service, then assign a defined percentage of end-user traffic to each version. This requires minimal refactoring of the existing web application from Compute Engine, as App Engine supports all common web runtimes, and the native traffic splitting feature removes the need to manage custom load balancer rules or routing logic for the conversion test. This directly addresses the scenario requirements with the least operational and development overhead, aligned with GCP best practices. B. Incorrect. Separate App Engine services are intended for distinct, decoupled components of an application (e.g. a frontend service, backend API service, and admin service), not for different variants of the same frontend. Deploying three separate services would require implementing custom traffic routing at the external load balancer or CDN layer to split user traffic between the three service endpoints, adding unnecessary operational complexity and cost that is not required when using native version-level traffic splitting. C. Incorrect. Cloud Functions are event-driven serverless compute resources designed for short-lived, single-purpose workloads triggered by specific events (e.g. cloud storage uploads, Pub/Sub messages, HTTP requests for discrete endpoints). They are not designed to host full end-to-end website deployments, and do not offer native traffic splitting capabilities for full web workloads. Refactoring an entire existing website from Compute Engine to Cloud Functions would require significant unnecessary development effort for this temporary testing use case. D. Incorrect. Deploying three separate Cloud Functions for the three website designs combines the drawbacks of option B and C: it requires full refactoring of the website to a function-based architecture, plus custom traffic routing to split users between the three independent function endpoints. This approach is operationally complex, costly, and misaligned with the intended use case for Cloud Functions, making it an invalid solution for this scenario. Key Concepts: 1. App Engine Version and Traffic Splitting: App Engine organizes deployments into services, each with multiple independent versions. Native traffic splitting across versions supports use cases including canary rollouts, A/B/n testing, and incremental feature launches, eliminating the need for custom routing infrastructure. 2. Workload Placement for GCP Compute Services: Matching compute services to workload requirements is a core Professional Cloud Developer competency. App Engine is optimized for managed web application hosting, while Cloud Functions are optimized for event-driven, discrete workloads, so selecting the appropriate service reduces development and operational overhead. 3. A/B/n Testing Best Practices: For user-facing conversion testing, native platform traffic splitting ensures consistent user assignment, accurate performance measurement, and minimal disruption to end users, which is preferred over custom routing implementations. References: Splitting Traffic, Google Cloud App Engine Documentation, https://cloud.google.com/appengine/docs/standard/splitting-traffic Professional Cloud Developer Certification Guide, Google Cloud